System, method and computer program product for remote vehicle diagnostics, monitoring, configuring and reprogramming

ABSTRACT

A remote vehicle diagnostics, monitoring, configuration and reprogramming tool is provided. The system includes a fleet of vehicles equipped with wireless mobile communications means that enable fleet managers to remotely diagnose, monitor and reprogram vehicles in their fleet via an Internet Web-based browser environment. Each vehicle within the fleet is equipped with a smart device that is coupled to the data bus within each vehicle. Date commands relating to the vehicle&#39;s parameters (e.g., diagnostic parameters such as max road speed, engine RPM, coolant temperature, air inlet temperature, etc.) are sent and received using satellite and terrestrial wireless communications technology. The invention allows users to remotely perform total fleet logistics and eliminates (or reduces) the need to physically bring fleet vehicles to a repair, maintenance or configuration facility.

PRIORITY

The present application is a United States national stage applicationclaiming the benefit of PCT/US01/24616, filed on Aug. 6, 2001, whichclaims the benefit of U.S. application Ser. No. 09/640,785, filed onAug. 21, 2000, now abandoned.

FIELD OF THE INVENTION

The present invention relates generally to computer data and informationsystems, and more particularly to computer tools for storing,processing, and displaying fleet vehicle information.

RELATED ART

In today's business environment, it is common for companies to own alarge amount (i.e., a fleet) of motor vehicles. A company, depending ontheir particular line of business, may have a fleet of passenger cars,light trucks, vans, heavy trucks or any combination of theses types ofvehicles. Typical examples of such companies include commercial courierservices, moving companies, freight and trucking companies, as well aspassenger vehicle leasing companies and passenger carriers.

Such companies must typically manage each of the hundreds of vehiclewithin their fleets. The most critical management operations include themaintenance and repair, and maximizing the efficiency of these vehicles.In addition, timely reporting of key information related to the vehicle,such as mileage, trip information, fluid status, and other parametersmust be available in a timely fashion. In order to maximize profits, acompany must maximize the amount of time each vehicle spends performingits intended function. That is, a company must minimize the amount oftime each vehicle spends in a service environment (i.e., a repair andmaintenance facility). Further complicating the situation is the factthat the vehicles within a company's fleet may operate throughout thenation's roads, but repair and maintenance facilities and vehicleconfiguration facilities are sparsely located in certain geographiclocations.

One management technique has traditionally been to schedule vehicles forroutine inspections on a rotating basis. While this technique hasimproved efficiency somewhat, it still involves taking a percentage ofthe fleet's vehicles out of service when in fact, they may not need tobe in a service environment or may not be available to be serviced orconfigured.

One development has led to the decrease in the amount of time vehiclesneeded to be in the service environment during routine inspections. Thatis, during the '70s and early 1980's manufacturers started usingelectronic means to control engine functions and diagnose engineproblems. This effort was primarily motivated to meet new and tougherEnvironmental Protection Agency (EPA) emission standards. Nevertheless,onboard diagnostic systems eventually became more sophisticated.Vehicles today typically include several controllers attached to avehicle data bus that allow the engine and parts of the vehicle'schassis, body and accessory devices to be monitored.

Several instruments were designed to take advantage of vehicles onboarddiagnostic and control systems. First, there were large pieces ofequipment to perform diagnostics and these were followed by hand-helddevices. These instruments increased the speed and efficiency of vehiclemaintenance and configuration. Such instruments, however, did noteliminate the need for vehicles, which may be operating nation-wide, tobe brought to a centralized (or regional) repair and maintenancefacility. That is, these devices needed to be connected directly to thevehicle. Further, there still has not been any systematic way forcompanies to remotely diagnose, monitor or configure their fleet'svehicles. That is, routine maintenance or configuration on a rotatingbasis is arbitrary and not based on which specific vehicles reallyrequire service.

Therefore, given the above, what is needed is a system, method, andcomputer program product for remote vehicle diagnostics, monitoring,configuring and reprogramming. The system, method, and computer programproduct should allow fleet managers, without heavy infrastructureadditions, to take advantage of today's vehicle's onboard diagnosticsystems, computer advances, and mobile communications in order toremotely diagnose, monitor and reprogram their fleet's vehicles.

SUMMARY OF THE INVENTION

The present invention meets the above-mentioned needs by providing asystem, method, and computer program product for remote vehiclediagnostics, monitoring, configuring and reprogramming.

The system of the present invention allows a user to perform total fleetlogistics by facilitating vehicle parameter changes, vehicle healthtracking, and receipt of vehicle maintenance need indications, thuseliminating the need to physically bring vehicles to a repair andmaintenance facility. More specifically, the system includes a pluralityof vehicles each having an onboard unit as described herein. The onboardunit is coupled to the vehicle data bus of each of the plurality ofvehicles, which in turn is connected to the vehicle's severalcontrollers.

The system further includes an application server which provides theuser with a graphical user interface (GUI) (e.g., Web pages over theInternet) in order to send and receive data from each of the pluralityof vehicles. A repository database, accessible via the applicationserver, is also included which stores information related to thesubscribers of the system and the specifics in relation to the vehiclesin their fleet.

An onboard unit server, coupled to the application server, is alsoincluded which contains means to convert command data between a formatunderstandable by the user using the GUI (e.g., change max cruise speedto 55 MPH”) and a format understandable by the vehicle data bus of eachof the plurality of vehicles (e.g., a binary data stream). Finally, thesystem includes a communications means, coupled to the onboard unitserver, for handling (mobile) communications between the onboard unitserver and the onboard units located on each of the plurality ofvehicles.

The method and computer program product of the present inventionincludes the steps of accessing the repository database in order toprovide the user with a list of specific vehicles within the fleet andthe vehicles' associated vehicle parameters. Next, a command from theuser is received via the GUI. The command typically includes informationspecifying at least one vehicle within the fleet and at least onevehicle parameter. Then, the command is stored in the repositorydatabase along with the time and date that the command was received fromthe user. Next, the command is converted from a format understandable bythe user using the GUI, to a format understandable by the vehicle databus of the at least one vehicle within the fleet.

The method and computer program product of the present invention furtherincludes sending the command, via a wireless mobile communicationssystem to the onboard unit located on the targeted vehicle within thefleet. This causes the previously specified vehicle parameter to be reador changed (depending on whether, for example, the command was relatedto diagnostic or reprogramming activities respectively). Next, anacknowledgment of the command is received from the vehicle via thewireless mobile communications system. Finally, the acknowledgment isstored in the repository database so that the user may later retrieve itusing the GUI.

One advantage of the present invention is that it allows a large fleet(e.g., several hundred) of commercial vehicles (e.g., a fleet ofcommercial delivery vans and/or trucks), of different makes and models,to be remotely configured, monitored, re-calibrated, and diagnosedwithout having to be brought to a centralized location (e.g., companyheadquarters). That is, the present invention provides a means forobtaining “total population” vehicle information.

Another advantage of the present invention is that it provides tamperingalert notification should any vehicle parameter be changed withoutauthorization once the vehicle leaves a company location orheadquarters.

Another advantage of the present invention is that it provides users(e.g., fleet managers, vehicle distributors, vehicle dealers and thelike) with a consistent graphical user interface, regardless of thevehicle makes and models that comprise their fleet.

Another advantage of the present invention is that it enables users toobtain real-time fleet characteristics, trend analysis and diagnostics,as well as allow fleet managers to provide real-time driver/fleetnotification.

Yet another advantage of the present invention is that it allowsparametric data capture, diagnostic code capture, trip data capture,system reconfiguration, system re-calibration, and correlation analysisto be performed on a fleet of vehicles on a customer-specified schedule.

Further features and advantages of the invention as well as thestructure and operation of various embodiments of the present inventionare described in detail below with reference to the accompanyingdrawings.

BRIEF DESCRIPTION OF THE FIGURES

The features and advantages of the present invention will become moreapparent from the detailed description set forth below when taken inconjunction with the drawings in which like reference numbers indicateidentical or functionally similar elements. Additionally, the left-mostdigit of a reference number identifies the drawing in which thereference number first appears.

FIG. 1 is a block diagram illustrating the system architecture of anembodiment of the present invention, showing connectivity among thevarious components;

FIG. 2A is a block diagram of the physical architecture of an onboardunit according to a preferred embodiment of the present invention;

FIG. 2B is a block diagram of the software architecture of an onboardunit according to a preferred embodiment of the present invention;

FIG. 3 is a flowchart depicting an embodiment of the operation andcontrol flow of the remote vehicle diagnostics, monitoring andreprogramming tool of the present invention,

FIGS. 4A–4D are windows or screen shots, relating to vehicle alerts,generated by the graphical user interface of the present invention;

FIGS. 5A–5G are windows or screen shots, relating to vehicle parameterreadings, generated by the graphical user interface of the presentinvention;

FIGS. 6A–6D are windows or screen shots, relating to vehicle parameterreprogramming, generated by the graphical user interface of the presentinvention; and

FIG. 7 is a block diagram of an exemplary computer system useful forimplementing the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Table of Contents

-   I. Overview-   II. System Architecture-   III. On Board Units-   IV. Detailed Example of System Operation-   V. Graphical User Interface-   VI. Example Implementations-   VII. Conclusion

I. Overview

The present invention relates to a system, method, and computer programproduct for remote commercial vehicle diagnostics, monitoring,configuring and reprogramming. The remote vehicle diagnostics,monitoring, configuration and reprogramming tool described herein willbecome essential to any business concern which deals with commercialfleet maintenance and service operations (i.e., it is a “total fleetlogistics” tool).

In an embodiment of the present invention, an application serviceprovider provides and allows access, on a subscriber basis, to a remotevehicle diagnostics, monitoring, configuration and reprogramming toolvia the global Internet. That is, the application service provider wouldprovide the hardware (e.g., servers) and software (e.g., database)infrastructure, application software, customer support, and billingmechanism to allow its customers (e.g., fleet managers, vehicledistributors, vehicle dealers, original equipment manufacturers (OEM),leasing/rental companies, and the like) to remotely diagnose, monitor,configure and/or reprogram, as appropriate, the vehicles within a fleet.The tool would be used by subscribers to obtain real-time fleetcharacteristics, trend analysis and diagnostics, to perform manual,dynamic or rule based configuration, as well as allow fleet managers toprovide real-time driver/fleet notification.

More specifically, the application service provider would provide aWorld Wide Web site where a fleet manager, using a computer and Webbrowser software, to remotely diagnose, monitor, configure, and/orreprogram the commercial vehicles for which they are responsible. Suchfleet managers would include, for example, those responsible foroverseeing a fleet of trucks for a commercial trucking or deliverycompany. Other users of the remote vehicle diagnostics, monitoring,configuring, and reprogramming tool would also include vehicle dealers,OEMs, and distributors who wish to obtain data concerning theperformance of the vehicles within a fleet for “market intelligence” or“improved performance” purposes.

In an alternate embodiment, the remote vehicle diagnostics, monitoring,configuring and reprogramming tool of the present invention maybe run,instead of on the global Internet, locally on proprietary equipmentowned by the customers (i.e., the fleet managers, vehicle distributors,vehicle dealers and the like) as a stand alone software application. Inyet another embodiment, users may access the remote vehicle diagnostics,monitoring, configuring and reprogramming tool of the present inventionvia direct dial-up lines rather than through the global Internet.

The remote vehicle diagnostics, monitoring, configuring, andreprogramming tool of the present invention would be utilized, assuggested above, by fleet manager users, for example, in order tofacilitate vehicle parameter changes, track vehicle health, and/orreceive indications of vehicle maintenance needs.

In an alternate embodiment, the remote vehicle diagnostics, monitoring,configuring and reprogramming tool of the present invention would beutilized by a vehicle component suppliers to re-calibrate any vehiclecomponent, perform firmware downloads, perform component failureanalysis, and determine wear characteristics.

In an alternate embodiment, the remote vehicle diagnostics, monitoring,configuring and reprogramming tool of the present invention would beutilized by vehicle manufacturers to analyze quality of components (andthus, suppliers) utilized in their manufacturing processes, and/orretrieve and manage warranty information.

In yet another embodiment, the remote vehicle diagnostics, monitoring,configuring and reprogramming tool of the present invention would beutilized by vehicle leasing companies to receive indications of vehiclemaintenance needs, monitor vehicle use and abuse, and/or monitor lesseetrip information.

In yet another alternate embodiment, the remote vehicle diagnostics,monitoring and reprogramming tool of the present invention would beutilized by vehicle dealers or vehicle repair facility personnel toperform proactive data analysis, perform pre-arrival diagnostics,re-calibrate vehicle components, and/or perform firmware downloads.

The present invention is described in terms of the above examples. Thisis for convenience only and is not intended to limit the application ofthe present invention. In fact, after reading the following description,it will be apparent to one skilled in the relevant art(s) how toimplement the following invention in alternative embodiments (e.g., toremotely manage different types and different aspects ofvehicles—non-commercial or commercial, etc.).

The terms “user,” “subscriber,” “company,” “business concern,” and theplural form of these terms are used interchangeably throughout herein torefer to those who would access, use, and/or benefit from the remotevehicle diagnostics, monitoring and reprogramming tool of the presentinvention.

II. System Architecture

Referring to FIG. 1, a block diagram illustrating the physicalarchitecture of a total fleet logistics (“TFL”) system 100, according toan embodiment of the present invention. FIG. 1 also shows networkconnectivity among the various components.

The TFL system 100 includes a plurality of users 102 (e.g., fleetmanagers, vehicle distributors, OEMs, vehicle dealers and the like)which would access to system 100 using a personal computer (PC) (e.g.,an IBM™ or compatible PC workstation running the Microsoft® Windows95/98™ or Windows NT™ operating system, Macintosh® computer running theMac® OS operating system, or the like), running a commercially availableWeb browser. In alternative embodiments, users 102 may access TFL system100 using any processing device including, but not limited to, a desktopcomputer, laptop, palmtop, workstation, set-top box, personal dataassistant (PDA), and the like.

The users 102 would connect to the parts (i.e., infrastructure) of theTFL system 100 which are provided by the TFL application serviceprovider (i.e., elements 106–124 of FIG. 1) via the global Internet 104.The connection to the Internet 104, however, is through a firewall 106.The components of the TFL system 100 are divided into tworegions—“inside” and “outside.” The components in the “inside” regionrefer to those components that the TFL application service providerwould have as part of their infrastructure in order to provide the toolsand services contemplated by the present invention. As will be apparentto one skilled in the relevant art(s), all of components “inside” of theTFL system 100 are connected and communicate via a wide or local areanetwork (WAN or LAN) running a secure communications protocol (e.g.,secure sockets layer (SSL)). The firewall 106 serves as the connectionand separation between the LAN, which includes the plurality of elements(e.g., elements 108–124) “inside” of the LAN, and the global Internet104 “outside” of the LAN. Generally speaking, a firewall is a dedicatedgateway machine (e.g., a SUN Ultra 10) with special security precautionsoftware. It is typically used, for example, to service Internet 104connections and dial-in lines, and protects the cluster of more looselyadministered network elements hidden behind it from external invasion.Firewalls are well known in the relevant art(s) and firewall software isavailable from many vendors such as Check Point Software TechnologiesCorporation of Redwood City, Calif.

TFL system 100 also includes two servers—an application server 108 andan onboard unit server (“OBU”) 118.

The application server 108 is the “back-bone” (i.e., TFL processing) ofthe present invention. It provides the “front-end” for the TFL system100. That is, application server 108 includes a Web service 110 which isa typical Web server process running at a Web site which sends out Webpages in response to Hypertext Transfer Protocol (HTTP) requests fromremote browsers (i.e., subscribers 102 of the TFL application serviceprovider ). More specifically, a Web server 112 provides graphical userinterface (GUI) “front-end” screens to users 102 of the TFL system 100in the form of Web pages. These Web pages, when sent to the subscriber'sPC (or the like), would result in GUI screens being displayed. In anembodiment of the present invention, the server 112 would be implementedusing a Netscape Enterprise or compatible Web server, an Apache webserver or the like. Connected to the server 112 is an application server114 which facilitates the data and commands between a repositorydatabase 116 and the Web pages on Web server 112. In an embodiment ofthe present invention, the server 114 would be an Oracle applicationserver.

Also included in the application server 108 is a TFL repository database116. Database 116, in an embodiment of the present invention, is a SunE250 machine running the Oracle 8iRDBMS (relational database managementserver) software. The database 116 is the central store for allinformation within the TFL system 100 and also stores Web pageexecutable code (e.g., PL/SQL and HTML).

The OBU server 118 is responsible, generally, for routing data betweenthe smart device onboard units 130 within each vehicle (explained indetail below) and the application server 108. The OBU server 118includes three software modules, implemented in a high level programminglanguage such as the C++ programming language—a dispatcher 120, acommunications service 122, and a conversion service 124. The dispatcher120 is a software module resident on the OBU server 118 and isresponsible for serving as an intermediary to route messages between theremaining two components of the OBU server 118 (i.e., the communicationsservice 122 and the conversion service 124).

The communications service 122 is a module that contains software codelogic that is responsible for handling in-bound and out-bound vehicledata and commands. As will be described in more detail below, thecommunications service 122 is configured for the specific means ofmobile communications employed within TFL system 100 (e.g., satellite orterrestrial wireless).

The conversion service 124 is a module that contains software code logicthat is responsible for converting raw vehicle data (i.e., telemetry)into human-readable format, and vice-versa. In an embodiment of thepresent invention, the conversion service 124 module includes arelational database implemented in Microsoft® Access or the like whichstores telemetry data definitions for a plurality of vehicle makes,models, and associated components. Such definitions would includevehicle component masks, bit length, and data stream order definitionsfor various vehicle (and component) manufacturers in order to performthe binary (raw) data conversion into human-readable form, andvice-versa.

TFL system 100 also includes an administrative workstation 134. Thisworkstation can be used by personnel of the TFL application serviceprovider to upload, update, and maintain subscriber information (e.g.,logins, passwords, etc.) and fleet-related data for each of the users102 that subscribe to the TFL system 100. The administrative workstation134 may also be used to monitor and log statistics related to theapplication server 108 and system 100 in general. Also, theadministrative workstation 134 may be used “off-line” by subscribers 102of the TFL system 100 in order to enter configuration data for supportedcontrollers 132, etc. within their fleet(s). This data is eventuallystored in TFL repository database 116.

TFL system 100 also includes a plurality of vehicles 128 (i.e., the“fleet” being remotely diagnosed, monitored and/or reprogrammed). (FIG.1 shows only one vehicle 128 for ease of explanation herein.) Withineach vehicle is a smart device onboard unit 130, explained in moredetail below. In an embodiment of the present invention, the onboardunits 130 have access to a plurality of controllers or discretemeasurement points 132 (shown as controllers 132 a–n in FIG. 1) foundwithin the vehicle 128 (e.g., brake, engine, transmission, and variousother vehicle electrical component controllers). Such access is thoughthe vehicle data bus (not shown) of each of the vehicles 128. Further,the onboard units 130 include transceivers that communicate with acommunications service provider. 126. Like the communications servicemodule 122, the onboard units 130 are configured for the specific meansof wireless mobile communications employed within TFL system 100 (e.g.,satellite or terrestrial wireless).

More detailed descriptions of the TFL system 100 components, as welltheir functionality, are provided below.

III. On Board Units

Referring to FIG. 2A, a block diagram of the physical architecture ofthe onboard unit 130, in a preferred embodiment of the presentinvention, is shown. The onboard unit 130 handles communications betweenthe vehicle controllers 132 and the remainder of the TFL system 100.

In a preferred embodiment of the present invention, the onboard unit 130is a small (e.g., 5″×6″×2″) computer board which contains a 32-bit RISCarchitecture central processing unit (CPU) 202 such as the Intel® StrongARM 32-bit chip, a 4 megabyte (MB) random access memory (RAM) 204, a 4MB flash memory 206, a power supply 208, and a compact flash interfacememory 210.

Further, onboard unit 130 also includes a user interface channel ports212 and a vehicle interface channel ports 214. In an embodiment of thepresent invention, the user interface channel ports 212 containinterface modules for several wire and wireless mobile communicationsstandard devices such as universal serial bus (USB), standard parallelports, standard serial ports, satellite communications, code divisionmultiple access (CDMA), time division multiple access (TDMA), theBluetooth® wireless standard chip, intellect data bus (IDB), and thelike. This would allow the TFL application service provider to utilizeseveral of the available providers 126 to communicate with vehicles 128in their subscriber's fleets.

In an embodiment of the present invention, the vehicle interface channelports 214 contain interface modules for several standard automotiveapplication program interfaces (API's). Such API's include Serial DataCommunications Between Microcomputer Systems in Heavy-Duty VehicleApplications, Document No. J1708, Society of Automotive Engineers (SAE)of Warrendale, Pa. (October 1993); Joint SAE/TMC Electronic DataInterchange Between Microcomputer Systems in Heavy-Duty VehicleApplications, Document No. J1587, SAE (July 1998); and RecommendedPractice for Truck and Bus Control and Communications Network, DocumentNo. J1939, SAE (April 2000); all of which are incorporated herein byreference in their entirety. Other such API's include SAE's onboarddiagnostic system (OBD) II standard and several vehicle manufacturerspecific/proprietary interfaces and discrete measurement pointinterfaces.

Referring to FIG. 2B, a block diagram of the software architecture ofthe onboard unit 130, in a preferred embodiment of the presentinvention, is shown. Onboard unit 130 contains three main softwaremodules, implemented in a high level programming language such as theC++ programming language, and executing on the CPU 202. These modulesinclude a command server module 210, a plurality of application specificmodules 220 (shown as application specific modules 220 a–n), and a dataparser/requester module 230.

The command server module 210 contains software code logic that isresponsible for handling the receiving and transmitting of thecommunications from the provider 126 and relays such data to either thedata parser/requester module 230 or to one of the application specificmodules 220, as applicable.

The application specific modules 220 (one for each manufacturer specificcontroller 132 within the vehicle) each contain software code logic thatis responsible for handling interfacing between the command servermodule 210 to the vehicle data bus 240 (via data parser/requestor module230) for application specific (i.e., manufacturer specific) parameterreadings, alerts, configuration or reprogramming data (as explained indetail below).

The data parser/requester module 230 contains software code logic thatis also responsible for handling direct interfacing between the commandserver module 210 to the vehicle data bus 240 for non-applicationspecific (i.e., “generic” SAE J1708 or SAE1939 discrete measurementpoints) parameter readings, alerts, configuration or reprogramming data(as explained in detail below).

In an embodiment of the present invention, the onboard unit 130 isdesigned to be compliant with the SAE's Joint SAE/TMC RecommendedEnvironmental Practices for Electronic Equipment Design (Heavy-DutyTrucks), Document No. J1455 (August 1994) standard, which isincorporated herein by reference in its entirety, because it will be acomponent included (or installed) within vehicles 132. That is, theonboard unit 130 is physically mounted on the vehicle 128, electricallycoupled to the vehicle data bus 240 via the wiring harness of thevehicle 128, and packaged in a manner that resists environmental seepageof dirt and moisture, as well as withstands operational vibration.Further, the onboard unit 130 must be built to withstand, in a preferredembodiment, industrial temperature ranges of −40 to 85 degreescentigrade.

In an alternate embodiment of the present invention, the onboard unit130 would include a global positioning (GPS) receiver component, whichwould allow the TFL system 100 to provide location-based logisticalmanagement features to users 102.

More details of the onboard unit 130 architecture and functionality areprovided below in connection with the description of the TFL system 100operation.

IV. Detailed Example of System Operation

Referring to FIG. 3, a flow chart of a sample control flow 300,according to an embodiment of the present invention, is shown. Morespecifically, control flow 300 depicts a fleet manager user 102reprogramming a fleet vehicle parameter with reference to the elementsof TFL system 100 described above with reference to FIG. 1. (Also seeFIG. 6 described below.) Control flow 300 begins at step 302, withcontrol passing immediately to step 304.

In step 304, the user 102 enters their password in order to login intothe TFL system 100. Such login would be provided by a Web page sent outover the Internet 104 (and accessed by user 102 using a PC or the like)by Web service 110. Subscriber information would be kept by the TFLapplication service provider in the TFL repository database 116.

After the user is logged in, in step 306, the user then enters theirvehicle list selection. The vehicle choices (i.e., entire fleet(s),division(s) of vehicles within a fleet, or specific individual vehicles)available for selection are stored for each subscriber in the TFLrepository database 116. Once presented with a GUI of availablevehicles, in step 308, the user 102 would then enter the parameter(s)(e.g., max cruise speed) they would like to reprogram on the specificvehicle(s) selected in step 306. In step 310, the user 102 would enterthe new setting(s) (e.g., 55 MPH) for the selected parameter(s).

In step 312, the application server 108 receives the settings andtranslates the reprogramming request into a list of commands—one commandfor each vehicle—and forwards these commands to the dispatcher module120 located on the onboard unit (OBU) server 118. In step 314, thedispatcher 120 forwards each command to the conversion service 124. Instep 316, the conversion service 124 translates the user enteredsetting(s) (e.g., “55 MPH”) to a binary format understandable to theonboard unit 130 such that it can process the command according to therequirements of the targeted vehicle controller 132. This translation isfacilitated by the relational database (as described above) locatedwithin the conversion service 124. Once translated, the command (now inbinary) is sent back to the dispatcher 120.

In step 318, the conversion service 124 forwards the command to thecommunications service 122. In step 320, the communications service 122further encodes and compresses the command (for efficiency oftransmission), and routes the command, (passing the firewall 106 and)via the Internet 104, to the communications provider 126. In step 322,the communications provider 126 forwards the command to the onboard unit130 on the vehicle 128.

As mentioned above, step 322 may be accomplished, depending on theembodiment of the present invention (i.e., according to the provider 126selected by or available to the TFL application service provider), viaany wire or wireless mobile communications standard such as USB,parallel ports, serial ports, satellite communications, CDMA, TDMA, theBluetooth® wireless standard, IDB, and the like.

In an embodiment of the present invention, more than one communicationservice provider 126 (and thus more than one means of mobilecommunications) would be utilized by the TFL application serviceprovider in order to maximize the number of different vehicles 128belonging to different subscribers 102 that may be diagnosed, monitoredand/or reprogrammed by the TFL system 100. Consequently, the OBU server118 would contain multiple communications service 122 modules, eachconfigured for specific communication service provider 126.

In step 324, the command is received by the command server module 210executing on the CPU 202 of the onboard unit 130. In step 326, thecommand is forwarded to the vehicle data bus 240 by the data parserrequester module 230 executing on the CPU 202 of the onboard unit 130.The command thus finally reaches the appropriate controller 132 withinthe vehicle 128. Control flow 300 then ends as indicated by step 328.

As will be apparent to one skilled in the relevant art(s) after readingthe above, an acknowledgment of the reprogramming command from thevehicle 128 to the user 102 would flow in the reverse direction fromcontrol flow 300. Further, the acknowledgment would be stored indatabase 116 for the user 102 to (later) retrieve.

It should be understood that control flow 300, which highlights thereprogramming functionality of TFL system 100, is presented for examplepurposes only. The software architecture of the present invention issufficiently flexible and configurable such that users 102 may navigatethrough the system 100 in ways other than that shown in FIG. 3.

V. Graphical User Interface

As mentioned above, the application server 108 will provide a GUI forusers 102 (e.g., fleet managers, vehicle distributors, OEMs, vehicledealers and the like) to enter inputs and receive the outputs asdescribed, for example, in control flow 300. In an embodiment of thepresent invention, the GUI screens of the present invention may beclassified into three categories: alerts (e.g., threshold alerts, tamperwarnings, etc.), parameter readings, and reprogramming. FIGS. 4–6,presented below, show examples GUI screens reflecting these threecategories respectively. They also highlight the functionality andfeatures of TFL system 100 in general.

Referring to FIG. 4A, a “set alert” GUI screen 410 with representativedata, according to an embodiment of the present invention, is shown.Screen 400 includes a column 402 labeled “Vehicle Unit ID” whichindicates the vehicles within a fleet the user 102 has previouslyselected to receive alerts for. Screen 400 includes a column 404 labeled“Description” which indicates the type of vehicle 128 corresponding theVehicle Unit ID in column 402. Screen 400 also includes a column 406labeled “T. Codes” which is a check box the user 102 can select toindicate that they wish to track alert codes for all availableparameters within a specific vehicle 128. Lastly, screen 400 includes acolumn 408 labeled “Tamper” which is a check box the user 102 can selectto indicate whether they wish to track whether any parameter within aspecific vehicle 128 has been physically tampered with.

Referring to FIG. 4B, a “view alert” GUI screen 410 with representativedata, according to an embodiment of the present invention, is shown.Screen 410 includes a column 412 labeled “Reading Date/Time” whichindicates the actual date and time a particular alert was generated fora particular vehicle specified in a column 414 labeled “Vehicle ID.” Ina column 416, the parameter name (e.g., vehicle speed limit) for whichthe alert was generated is displayed. Screen 410 also includes a column418 labeled “Alert Value,” where a description of the alter isdisplayed.

Referring to FIG. 5A, a “select parameter” GUI screen 500, according toan embodiment of the present invention, is shown. Screen 500 includesfour categories 502 a–d of parameters a user 102 may select. Within eachcategory 502, there are specific vehicle parameters 504 a–d that theuser 102 may choose from. Selected parameters 504 or categories ofparameters 502 will result in the TFL system 100 system obtaining theseparameter readings from each of the vehicles 128 that the user 102 haspreviously selected.

Referring to FIG. 5B, a “select parameter transactions” GUI screen 510with representative data, according to an embodiment of the presentinvention, is shown. Screen 510 includes a column 512 labeled“Transaction Description.” This column indicates the names of thedifferent transactions created by one or more users 102 which manage thesame fleet of vehicles. In an embodiment of the present invention, a“transaction” is a section of different parameter categories 502 and/orspecific vehicle parameters 504 selected by a user 102 using screen 500and saved in the TFL system 100 using a “transaction” name shown incolumn 512 of screen 510. A column 513 indicates the ID (i.e., loginname) of the particular user 102 which created the transaction. A column514 indicates the date that the user 102 created the transaction. Acolumn 516 labeled “Param Profile Requested” indicates the category 502of parameters that the user 102 selected in GUI screen 500 for thecorresponding transaction. A column 518 allows the user 102 to selectthe transactions they would like to view for the specific vehicles 128previously selected.

Referring to FIG. 5C, a “view parameter results” GUI screen 520,according to an embodiment of the present invention, is shown. Screen520 includes a column 522 labeled “Vehicle Unit ID” which indicates thevehicles within a fleet the user 102 has previously selected to receiveparameter readings from. Screen 520 also includes several parameterreading columns 524 which indicate the parameter values read from theselected vehicles 128 and correspond to the transaction selected by auser 102 using the select buttons in column 518 on screen 510.

Referring to FIG. 6A, an “enter parameter values for reprogramming” GUIscreen 600, according to an embodiment of the present invention, isshown. Screen 600 includes a column 602 labeled “Vehicle Unit ID” whichindicates the vehicles within a fleet the user 102 has previouslyselected to reprogram. (See control flow 300 described above withreference to FIG. 3.) Screen 600 includes a column 604 labeled“Description” which indicates the type of vehicle 128 corresponding theVehicle Unit ID in column 602. Screen 600 also includes a column 606labeled “Current Setting” which indicates the current value of thepreviously selected parameter that user 102 desires to reprogram (i.e.,change). Lastly, screen 600 includes a column 608 labeled “New Setting”which is an input box where the user can enter a new value for thepreviously selected vehicle 128 parameter.

Referring to FIG. 6B, a “view reprogramming results” GUI screen 610,according to an embodiment of the present invention, is shown. Screen610 includes a column 612 labeled “Vehicle” which indicates the vehicles132 within a fleet the user 102 has previously selected to reprogram. Acolumn 614 indicates the name of the previously selected vehicleparameter for which status information is now being viewed by user 102.A column 616 indicates the date and time that the user 102 submitted thereprogramming request using screen 600. A column 618 labeled “Current”indicates the present value (at last reading and presently stored inrepository 116) for the corresponding vehicle parameter shown in column614. A column 620 labeled “Requested” indicates the new reprogrammedvalue requested by user 102 using column 608 of screen 600. Screen 610also includes a column 622 labeled “Status” which indicates the currentstatus (as read from the vehicle 128) of the reprogramming command sentby the TFL system 100.

It should be understood that the screens shown in this section (i.e.,FIGS. 4–6), which highlights the functionality of TFL system 100, arepresented for example purposes only. The software architecture (andthus, GUI screens) of the present invention is sufficiently flexible andconfigurable such that users 102 may navigate through the system 100 inways other than those shown in FIGS. 4–6. Further, the informationdescribed therein can be presented to the user 102 in ways other thanshown in FIGS. 4–6.

In an embodiment of the present invention, reprogramming commands to besent to specific vehicles 128 and parameter readings to be read fromspecific vehicles 128 can be scheduled by the TFL system 100. That is,the user 102 may specify, for example, pre-defined time periods thatparameter readings should be taken for specific vehicles within a fleet.Such pre-defined time periods can be hourly, daily, x times per day,weekly, y times per week, monthly, etc.

VI. Example Implementations

The present invention (i.e., TFL system 100, onboard unit 130, controlflow 300, and/or any part(s) thereof) may be implemented using hardware,software or a combination thereof and may be implemented in one or morecomputer systems or other processing systems. In fact, in oneembodiment, the invention is directed toward one or more computersystems capable of carrying out the functionality described herein. Anexample of a computer system 700 is shown in FIG. 7. The computer system700 includes one or more processors, such as processor 704. Theprocessor 704 is connected to a communication infrastructure 706 (e.g.,a communications bus, cross-over bar, or network). Various softwareembodiments are described in terms of this exemplary computer system.After reading this description, it will become apparent to a personskilled in the relevant art(s) how to implement the invention usingother computer systems and/or computer architectures.

Computer system 700 can include a display interface 705 that forwardsgraphics, text, and other data from the communication infrastructure 702(or from a frame buffer not shown) for display on the display unit 730.

Computer system 700 also includes a main memory 708, preferably randomaccess memory (RAM), and may also include a secondary memory 710. Thesecondary memory 710 may include, for example, a hard disk drive 712and/or a removable storage drive 714, representing a floppy disk drive,a magnetic tape drive, an optical disk drive, etc. The removable storagedrive 714 reads from and/or writes to a removable storage unit 718 in awell known manner. Removable storage unit 718, represents a floppy disk,magnetic tape, optical disk, etc. which is read by and written to byremovable storage drive 714. As will be appreciated, the removablestorage unit 118 includes a computer usable storage medium having storedtherein computer software and/or data.

In alternative embodiments, secondary memory 710 may include othersimilar means for allowing computer programs or other instructions to beloaded into computer system 700. Such means may include, for example, aremovable storage unit 722 and an interface 720. Examples of such mayinclude a program cartridge and cartridge interface (such as that foundin video game devices), a removable memory chip (such as an EPROM, orPROM) and associated socket, and other removable storage units 722 andinterfaces 720 which allow software and data to be transferred from theremovable storage unit 722 to computer system 700.

Computer system 700 may also include a communications interface 724.Communications interface 724 allows software and data to be transferredbetween computer system 700 and external devices. Examples ofcommunications interface 724 may include a modem, a network interface(such as an Ethernet card), a communications port, a PCMCIA slot andcard, etc. Software and data transferred via communications interface724 are in the form of signals 728 which may be electronic,electromagnetic, optical or other signals capable of being received bycommunications interface 724. These signals 728 are provided tocommunications interface 724 via a communications path (i.e., channel)726. This channel 726 carries signals 728 and may be implemented usingwire or cable, fiber optics, a phone line, a cellular phone link, an RFlink and other communications channels.

In this document, the terms “computer program medium” and “computerusable medium” are used to generally refer to media such as removablestorage drive 714, a hard disk installed in hard disk drive 712, andsignals 728. These computer program products are means for providingsoftware to computer system 700. The invention is directed to suchcomputer program products.

Computer programs (also called computer control logic) are stored inmain memory 708 and/or secondary memory 710. Computer programs may alsobe received via communications interface 724. Such computer programs,when executed, enable the computer system 700 to perform the features ofthe present invention as discussed herein. In particular, the computerprograms, when executed, enable the processor 704 to perform thefeatures of the present invention. Accordingly, such computer programsrepresent controllers of the computer system 700.

In an embodiment where the invention is implemented using software, thesoftware may be stored in a computer program product and loaded intocomputer system 700 using removable storage drive 714, hard drive 712 orcommunications interface 724. The control logic (software), whenexecuted by the processor 704, causes the processor 704 to perform thefunctions of the invention as described herein.

In another embodiment, the invention is implemented primarily inhardware using, for example, hardware components such as applicationspecific integrated circuits (ASICs). Implementation of the hardwarestate machine so as to perform the functions described herein will beapparent to persons skilled in the relevant art(s).

In yet another embodiment, the invention is implemented using acombination of both hardware and software.

VI. Conclusion

While various embodiments of the present invention have been describedabove, it should be understood that they have been presented by way ofexample, and not limitation. It will be apparent to persons skilled inthe relevant art(s) that various changes in form and detail can be madetherein without departing from the spirit and scope of the invention.Thus the present invention should not be limited by any of theabove-described exemplary embodiments, but should be defined only inaccordance with the following claims and their equivalents.

1. A system for allowing a user to perform remote vehicle diagnostics,vehicle monitoring, vehicle configuration and vehicle reprogramming forat least one vehicle, comprising: an onboard unit coupled to a data busof the at least one vehicle, wherein the onboard unit is operable toexchange with the data bus telemetry data that is in a format native toat least one vehicle controller coupled to the data bus, and wherein theonboard unit includes a first communication means that is operable toexchange the telemetry data over a first network; a server comprising: asecond communications means that is operable to exchange the telemetrydata with the onboard unit via the first network; an onboard-unit serverthat is operable to convert the telemetry data between the native formatand a human readable format so as to provide converted telemetry data; arepository database for holding information indicative of at least oneof the vehicles; an application server, coupled to the onboard-unitserver and the repository database, having at least one application forcarrying out at least one of vehicle diagnostics, vehicle monitoring,vehicle configuration and vehicle reprogramming, wherein the applicationserver is operable to carry out decision processing of the at least oneapplication to generate processed information as a function of at leasta portion of the information from the repository database and theconverted telemetry data; and a network interface that is operable toexchange with at least one application the processed information, andresponsive to a user request, provide at least a portion of theprocessed information and converted telemetry data over a secondnetwork; a graphical-user interface coupled to the network interface viathe second network, wherein graphical-user interface is operable tosubmit the user request, exchange with the network interface at least aportion of the processed information and the converted telemetry dataresponsive to the request, and display at least a portion of theprocessed information and the converted telemetry data to the user;wherein at least the application server is provided by an applicationservice provider; and wherein the user is charged a fee by theapplication service provider.
 2. The system of claim 1, wherein the atleast one vehicle includes at least one of the group consisting of (i)passenger cars; (ii) light trucks; (iii) vans; (iv) heavy trucks, and(v) other movable vehicles.
 3. The system of claim 2, wherein at least aportion of the second communications means includes any wire or wirelessmobile communications.
 4. The system of claim 1, wherein the firstnetwork includes at least one path routed through the Internet.
 5. Thesystem of claim 1, wherein the telemetry data is in binary format. 6.The system of claim 1, wherein the system provides total fleet logisticsvia the GUI by facilitating vehicle parameter changes, vehicle healthtracking, and receipt of vehicle maintenance need indications, therebyeliminating a need to physically bring the one or more vehicles torepair, maintenance, or configuration facility.
 7. The system of claim1, wherein onboard unit comprises an application module, adata-interface module, and a command module.
 8. The system of claim 7,wherein, the application module is operable to collect telemetry datafor any of the applications, and manage interfacing between the data busand the command module for collecting the telemetry data; wherein thedata interface module is operable to manage interfacing between the databus, the application and command modules; and wherein the command moduleis operable to manage telemetry data sent to and from the onboard unit,and direct the telemetry data to the data-bus interface and applicationmodule.
 9. The system of claim 8, wherein the onboard-unit serverincludes a dispatcher module, a conversion module, and a communicationmodule, wherein the dispatcher module is operable to route the telemetrydata between the communication and conversion modules, wherein thecommunication module is operable to manage telemetry data sent to andfrom the onboard-unit server, and wherein the conversion module isoperable to convert telemetry data between the native format and aformat understandable by the user using the GUI.
 10. The system of claim1, wherein the onboard-unit server includes a dispatcher module, aconversion module, and a communication module, wherein the dispatchermodule is operable to route the telemetry data between the communicationand conversion modules, wherein the communication module is operable tomanage telemetry data sent to and from the onboard-unit server, andwherein the conversion module is operable to convert telemetry databetween the native format and a format understandable by the user usingthe GUI.
 11. The system of claim 1, further including a firewall,wherein appropriate credentials are required to access to theapplication server and repository database.
 12. The system of claim 1,wherein the information indicative of the at least one vehicle includesa vehicle identification parameter and at least one parameter that isspecific to the applications.
 13. The system of claim 1, wherein thetelemetry data sent to and received from each of the at least onevehicle includes telemetry data specific to the applications.
 14. Thesystem of claim 1, wherein the information indicative of the at leastone vehicle includes a vehicle identification parameter and at least oneparameter that is not specific to the applications.
 15. The system ofclaim 1, wherein the telemetry data sent to each of the at least onevehicle contain commands for collecting data.
 16. The system of claim 1,wherein the telemetry data sent to each of the at least one vehiclecontains at least one command for setting a parameter of the vehicle.17. The system of claim 1, wherein to carry out the decision processingthe application server accesses the repository database to obtain theinformation about at least one vehicle.
 18. The system of claim 17,wherein during processing of applications telemetry data is exchangedwith at least one of the vehicles.
 19. The system of claim 1, whereinthe application server includes a web server, and wherein the graphicaluser interface accesses the application server via the web server. 20.The system of claim 1, wherein the application server includes a webserver, and wherein the GUI accesses the application server via the webserver.
 21. The system of claim 1, wherein the graphical user interfaceuses a web browser to access the application server.
 22. The system ofclaim 21, wherein the graphical user interface is not provided by theapplication service provider.
 23. The system of claim 1, wherein theonboard unit server and application server are provided by anapplication service provider.
 24. The system of claim 23, wherein theapplication server includes a web server, and wherein the graphical userinterface accesses the application server via the web server.
 25. Thesystem of claim 24, wherein the graphical user interface uses a webbrowser to access the application server.
 26. The system of claim 1,wherein the onboard unit server, application server, and graphical userinterface are provided as a locally-based standalone system.
 27. Thesystem of claim 26, wherein the application server includes a local areanetwork (LAN) server, and wherein the graphical user interface accessesthe application server via the LAN server.
 28. The system of claim 27,wherein the graphical user interface uses a browser to access theapplication server.
 29. A system for a vehicle onboard unit that allowsa user to perform remote vehicle diagnostics, vehicle monitoring,vehicle configuration and vehicle reprogramming, wherein the vehicleonboard unit is coupled to a data bus of a vehicle, the systemcomprising: a central processing unit (CPU); vehicle input/output (I/O)channel ports for exchanging with the data bus telemetry data that is ina format native to at least one vehicle controller coupled to the databus, and for exchanging the telemetry data over a first network; a firstapplication program interface means, executable by the CPU, forconverting the telemetry data between the native format and a humanreadable format so as to provide converted telemetry data; at least oneapplication server, executable by the CPU, for carrying out at least oneof vehicle diagnostics, vehicle monitoring, vehicle configuration andvehicle reprogramming, wherein the at least one application is operableto carry out decision processing to generate processed information as afunction of at least a portion of information that is obtained from arepository database and the converted telemetry data, wherein theinformation is indicative of the vehicle; user input/output (I/O)channel ports for exchanging with the at least one application theprocessed information, and exchanging with a graphical-user interfacemeans via a second network a user request for the processed informationand the converted telemetry data; a second application program interfacemeans, executing on said CPU, for extracting a command from user requestexchanged with the user I/O channel ports, wherein said command includesinformation specifying a vehicle and at least one vehicle parameterassociated with the vehicle; exchanging with thegraphical-user-interface means at least a portion of the processedinformation and converted telemetry data responsive to the requestwherein the system allows the user to perform total fleet logistics viathe graphical-user-interface means by facilitating vehicle parameterchanges, vehicle health tracking, and receipt of vehicle maintenanceneed indications, thus eliminating the need to physically bring saidvehicle to a repair, maintenance or configuration facility; wherein atleast the application server is provided by an application serviceprovider; and wherein the user is charged a fee by the applicationservice provider.
 30. The system of claim 29, wherein the secondapplication program interface means includes means for extracting thecommand from one of the following types of communications exchanged viathe user I/O channel ports: (i) satellite communications; (ii) codedivision multiple access (CDMA) communications; (iii) time divisionmultiple access (TDMA) communications; (iv) wireless local area networkcommunications; (v) wired local area network communications; (vi)controller area network communications; and (vii) wireless wide areanetwork communications.
 31. A method for allowing a user to performremote diagnostics, monitoring configuring, and reprogramming for afleet of vehicles, comprising: accessing a repository database using agraphical user interface (GUI) via a first network, wherein therepository database provides a list of vehicles within the fleet ofvehicles and a list of associated vehicle parameters; selecting, via theGUI, at least one vehicle from the list of vehicles, and one vehicleparameter from the list of associated vehicle parameters for each of theat least one vehicle; receiving from the GUI, via the first network, acommand requesting an application server to process at least oneapplication for carrying out any of vehicle diagnostics, vehiclemonitoring, vehicle configuration and vehicle reprogramming, wherein thecommand includes information specifying the at least one vehicle fromthe list of vehicles, and one vehicle parameter from the list ofassociated vehicle parameters for each of the at least one vehicle,wherein the application server is provided by an application serviceprovider and wherein the user is charged a fee by the applicationservice provider; storing the command with the time and date that thecommand was received in the repository database; responsive to thecommand, processing at least one application for converting the commandfrom a format understandable by the GUI to telemetry data that is in aformat native to at least one onboard unit located on said at least onevehicle; sending the telemetry data, via a wireless mobilecommunications system over a second network to cause the at least onevehicle parameter to be read or changed; receiving from said onboardunit, via the wireless mobile communications system, an acknowledgmentof the at least one vehicle parameter being read or changed; and storingthe acknowledgment in the repository database so that the GUI may laterretrieve the acknowledgment using the GUI responsive to a user requestsend via the second network, sending to the GUI via the second networkthe acknowledgment for display; whereby the method allows the user toperform total fleet logistics by facilitating vehicle parameter changes,vehicle health tracking, and receipt of vehicle maintenance needindications, thus eliminating the need to physically bring vehicle'swithin the fleet to a repair, maintenance, or configuration facility.32. The method of claim 31 wherein the first network includes at least aone path routed through the Internet.
 33. The method of claim 31,wherein at least a portion of the wireless mobile communications systemincludes at least one of the following: (i) a satellite communicationdevice; (ii) code division multiple access (CDMA) communication device;(iii) time division multiple access (TDMA) communication device; and(iv) a wireless local area network communications; (v) a wired localarea network communication device; and (vi) a wireless wide area networkcommunication device.
 34. A computer program product comprising acomputer usable medium having control logic stored therein for carryingout the method of claim
 31. 35. A system for allowing a user to performremote vehicle diagnostics, vehicle monitoring, vehicle configurationand vehicle reprogramming for at least one vehicle, comprising: anonboard unit coupled to the data bus of the at least one vehicle,wherein the onboard unit is operable to exchange with the data bustelemetry data that is in a format native to at least one vehiclecontroller coupled to the data bus, and wherein the onboard unitincludes a first communication means that is operable to exchange thetelemetry data over a first network; a server comprising: asecond-communications means that is operable to exchange the telemetrydata with the onboard unit via the first network; an onboard-unit serverthat is operable to convert the telemetry data between its native formatand a human readable format so as to provide converted telemetry data; arepository database for holding information indicative of at least oneof the vehicles; an application server, coupled to the onboard-unitserver and the repository database, having at least one application forcarrying out at least one of vehicle diagnostics, vehicle monitoring,vehicle configuration and vehicle reprogramming, wherein the applicationserver is operable to carry out decision processing of the at least oneapplication to generate processed information as a function of at leasta portion of the information from the repository database and theconverted telemetry data; and a network interface that is operable toexchange with at least one application the processed information, andresponsive to a user request, provide at least a portion of theprocessed information and the converted telemetry data over a secondnetwork; a graphical-user interface coupled to the network interface viathe second network, wherein graphical-user interface is operable tosubmit the user request, exchange with the network interface at least aportion of the processed information and the converted telemetry dataresponsive to the request, and display at least a portion of theprocessed information and converted telemetry data to the user; whereinat least the application server is provided by an application serviceprovider; and wherein the application service provider charges asubscription for carrying out the at least one application.